Method and apparatus of updating routing table of an iab (integrated access backhaul) node in a wireless communication system

ABSTRACT

A method and apparatus are disclosed from the perspective of a first node supporting wireless access and wireless backhaul. In one embodiment, the method includes the first node transmitting a first message to a second node, for updating a second routing path maintained by the second node.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims the benefit of U.S. Provisional PatentApplication Ser. No. 62/712,577 filed on Jul. 31, 2018, the entiredisclosure of which is incorporated herein in its entirety by reference.

FIELD

This disclosure generally relates to wireless communication networks,and more particularly, to a method and apparatus of updating routingtable of an IAB node in a wireless communication system.

BACKGROUND

With the rapid rise in demand for communication of large amounts of datato and from mobile communication devices, traditional mobile voicecommunication networks are evolving into networks that communicate withInternet Protocol (IP) data packets. Such IP data packet communicationcan provide users of mobile communication devices with voice over IP,multimedia, multicast and on-demand communication services.

An exemplary network structure is an Evolved Universal Terrestrial RadioAccess Network (E-UTRAN). The E-UTRAN system can provide high datathroughput in order to realize the above-noted voice over IP andmultimedia services. A new radio technology for the next generation(e.g., 5G) is currently being discussed by the 3GPP standardsorganization. Accordingly, changes to the current body of 3GPP standardare currently being submitted and considered to evolve and finalize the3GPP standard.

SUMMARY

A method and apparatus are disclosed from the perspective of a firstnode supporting wireless access and wireless backhaul. In oneembodiment, the method includes the first node transmitting a firstmessage to a second node, for updating a second routing path maintainedby the second node.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a diagram of a wireless communication system according toone exemplary embodiment.

FIG. 2 is a block diagram of a transmitter system (also known as accessnetwork) and a receiver system (also known as user equipment or UE)according to one exemplary embodiment.

FIG. 3 is a functional block diagram of a communication system accordingto one exemplary embodiment.

FIG. 4 is a functional block diagram of the program code of FIG. 3according to one exemplary embodiment.

FIG. 5 is a reproduction of FIG. 1 of 3GPP RP-172290.

FIG. 6 is a reproduction of FIG. 6.1.1-1 of 3GPP TR 38.874 V0.3.2.

FIG. 7 is a reproduction of FIG. 6.3.1-1 of 3GPP TR 38.874 V0.3.2.

FIG. 8 is a reproduction of FIG. 6.3.1-2 of 3GPP TR 38.874 V0.3.2.

FIG. 9 is a reproduction of FIGS. 9.2-1 of 3GPP TR 38.874 V0.3.2.

FIG. 10 is a reproduction of FIGS. 9.2-2 of 3GPP TR 38.874 V0.3.2.

FIG. 11 is a reproduction of FIGS. 9.2-3 of 3GPP TR 38.874 V0.3.2.

FIG. 12 is a reproduction of FIGS. 9.2-4 of 3GPP TR 38.874 V0.3.2.

FIG. 13 is a diagram according to one exemplary embodiment.

FIG. 14 is a diagram according to one exemplary embodiment.

FIG. 15 is a diagram according to one exemplary embodiment.

FIG. 16 is a diagram according to one exemplary embodiment.

FIG. 17 is a diagram according to one exemplary embodiment.

FIG. 18 is a diagram according to one exemplary embodiment.

FIG. 19 is a diagram according to one exemplary embodiment.

FIG. 20 is a flow chart according to one exemplary embodiment.

FIG. 21 is a flow chart according to one exemplary embodiment.

DETAILED DESCRIPTION

The exemplary wireless communication systems and devices described belowemploy a wireless communication system, supporting a broadcast service.Wireless communication systems are widely deployed to provide varioustypes of communication such as voice, data, and so on. These systems maybe based on code division multiple access (CDMA), time division multipleaccess (TDMA), orthogonal frequency division multiple access (OFDMA),3GPP LTE (Long Term Evolution) wireless access, 3GPP LTE-A orLTE-Advanced (Long Term Evolution Advanced), 3GPP2 UMB (Ultra MobileBroadband), WiMax, 3GPP NR (New Radio), or some other modulationtechniques.

In particular, the exemplary wireless communication systems devicesdescribed below may be designed to support one or more standards such asthe standard offered by a consortium named “3rd Generation PartnershipProject” referred to herein as 3GPP, including: TR 38.913 V14.1.0,“Study on Scenarios and Requirements for Next Generation AccessTechnologies”; RP-172290, “Study on Integrated Access and Backhaul forNR”; and TR 38.874 V0.3.2, “Study on Integrated Access and Backhaul”.The standards and documents listed above are hereby expresslyincorporated by reference in their entirety.

FIG. 1 shows a multiple access wireless communication system accordingto one embodiment of the invention. An access network 100 (AN) includesmultiple antenna groups, one including 104 and 106, another including108 and 110, and an additional including 112 and 114. In FIG. 1, onlytwo antennas are shown for each antenna group, however, more or fewerantennas may be utilized for each antenna group. Access terminal 116(AT) is in communication with antennas 112 and 114, where antennas 112and 114 transmit information to access terminal 116 over forward link120 and receive information from access terminal 116 over reverse link118. Access terminal (AT) 122 is in communication with antennas 106 and108, where antennas 106 and 108 transmit information to access terminal(AT) 122 over forward link 126 and receive information from accessterminal (AT) 122 over reverse link 124. In a FDD system, communicationlinks 118, 120, 124 and 126 may use different frequency forcommunication. For example, forward link 120 may use a differentfrequency then that used by reverse link 118.

Each group of antennas and/or the area in which they are designed tocommunicate is often referred to as a sector of the access network. Inthe embodiment, antenna groups each are designed to communicate toaccess terminals in a sector of the areas covered by access network 100.

In communication over forward links 120 and 126, the transmittingantennas of access network 100 may utilize beamforming in order toimprove the signal-to-noise ratio of forward links for the differentaccess terminals 116 and 122. Also, an access network using beamformingto transmit to access terminals scattered randomly through its coveragecauses less interference to access terminals in neighboring cells thanan access network transmitting through a single antenna to all itsaccess terminals.

An access network (AN) may be a fixed station or base station used forcommunicating with the terminals and may also be referred to as anaccess point, a Node B, a base station, an enhanced base station, anevolved Node B (eNB), a node, an access node, an IAB node, or some otherterminology. An access terminal (AT) may also be called user equipment(UE), a wireless communication device, terminal, access terminal or someother terminology.

FIG. 2 is a simplified block diagram of an embodiment of a transmittersystem 210 (also known as the access network) and a receiver system 250(also known as access terminal (AT) or user equipment (UE)) in a MIMOsystem 200. At the transmitter system 210, traffic data for a number ofdata streams is provided from a data source 212 to a transmit (TX) dataprocessor 214.

In one embodiment, each data stream is transmitted over a respectivetransmit antenna. TX data processor 214 formats, codes, and interleavesthe traffic data for each data stream based on a particular codingscheme selected for that data stream to provide coded data.

The coded data for each data stream may be multiplexed with pilot datausing OFDM techniques. The pilot data is typically a known data patternthat is processed in a known manner and may be used at the receiversystem to estimate the channel response. The multiplexed pilot and codeddata for each data stream is then modulated (i.e., symbol mapped) basedon a particular modulation scheme (e.g., BPSK, QPSK, M-PSK, or M-QAM)selected for that data stream to provide modulation symbols. The datarate, coding, and modulation for each data stream may be determined byinstructions performed by processor 230.

The modulation symbols for all data streams are then provided to a TXMIMO processor 220, which may further process the modulation symbols(e.g., for OFDM). TX MIMO processor 220 then provides N_(T) modulationsymbol streams to N_(T) transmitters (TMTR) 222 a through 222 t. Incertain embodiments, TX MIMO processor 220 applies beamforming weightsto the symbols of the data streams and to the antenna from which thesymbol is being transmitted.

Each transmitter 222 receives and processes a respective symbol streamto provide one or more analog signals, and further conditions (e.g.,amplifies, filters, and upconverts) the analog signals to provide amodulated signal suitable for transmission over the MIMO channel. N_(T)modulated signals from transmitters 222 a through 222 t are thentransmitted from N_(T) antennas 224 a through 224 t, respectively.

At receiver system 250, the transmitted modulated signals are receivedby N_(R) antennas 252 a through 252 r and the received signal from eachantenna 252 is provided to a respective receiver (RCVR) 254 a through254 r. Each receiver 254 conditions (e.g., filters, amplifies, anddownconverts) a respective received signal, digitizes the conditionedsignal to provide samples, and further processes the samples to providea corresponding “received” symbol stream.

An RX data processor 260 then receives and processes the N_(R) receivedsymbol streams from N_(R) receivers 254 based on a particular receiverprocessing technique to provide N_(T)“detected” symbol streams. The RXdata processor 260 then demodulates, deinterleaves, and decodes eachdetected symbol stream to recover the traffic data for the data stream.The processing by RX data processor 260 is complementary to thatperformed by TX MIMO processor 220 and TX data processor 214 attransmitter system 210.

A processor 270 periodically determines which pre-coding matrix to use(discussed below). Processor 270 formulates a reverse link messagecomprising a matrix index portion and a rank value portion.

The reverse link message may comprise various types of informationregarding the communication link and/or the received data stream. Thereverse link message is then processed by a TX data processor 238, whichalso receives traffic data for a number of data streams from a datasource 236, modulated by a modulator 280, conditioned by transmitters254 a through 254 r, and transmitted back to transmitter system 210.

At transmitter system 210, the modulated signals from receiver system250 are received by antennas 224, conditioned by receivers 222,demodulated by a demodulator 240, and processed by a RX data processor242 to extract the reserve link message transmitted by the receiversystem 250. Processor 230 then determines which pre-coding matrix to usefor determining the beamforming weights then processes the extractedmessage.

Turning to FIG. 3, this figure shows an alternative simplifiedfunctional block diagram of a communication device according to oneembodiment of the invention. As shown in FIG. 3, the communicationdevice 300 in a wireless communication system can be utilized forrealizing the UEs (or ATs) 116 and 122 in FIG. 1 or the base station (orAN) 100 in FIG. 1, and the wireless communications system is preferablythe NR system. The communication device 300 may include an input device302, an output device 304, a control circuit 306, a central processingunit (CPU) 308, a memory 310, a program code 312, and a transceiver 314.The control circuit 306 executes the program code 312 in the memory 310through the CPU 308, thereby controlling an operation of thecommunications device 300. The communications device 300 can receivesignals input by a user through the input device 302, such as a keyboardor keypad, and can output images and sounds through the output device304, such as a monitor or speakers. The transceiver 314 is used toreceive and transmit wireless signals, delivering received signals tothe control circuit 306, and outputting signals generated by the controlcircuit 306 wirelessly. The communication device 300 in a wirelesscommunication system can also be utilized for realizing the AN 100 inFIG. 1.

FIG. 4 is a simplified block diagram of the program code 312 shown inFIG. 3 in accordance with one embodiment of the invention. In thisembodiment, the program code 312 includes an application layer 400, aLayer 3 portion 402, and a Layer 2 portion 404, and is coupled to aLayer 1 portion 406. The Layer 3 portion 402 generally performs radioresource control. The Layer 2 portion 404 generally performs linkcontrol. The Layer 1 portion 406 generally performs physicalconnections.

Integrated Access and Backhaul (JAB) for NR is under study in 3GPPRP-172290. 3GPP RP-172290 provides the following description related toIAB:

3 Justification

One of the potential technologies targeted to enable future cellularnetwork deployment scenarios and applications is the support forwireless backhaul and relay links enabling flexible and very densedeployment of NR cells without the need for densifying the transportnetwork proportionately.

Due to the expected larger bandwidth available for NR compared to LTE(e.g. mmWave spectrum) along with the native deployment of massive MIMOor multi-beam systems in NR creates an opportunity to develop and deployintegrated access and backhaul links. This may allow easier deploymentof a dense network of self-backhauled NR cells in a more integratedmanner by building upon many of the control and data channels/proceduresdefined for providing access to UEs. An example illustration of anetwork with such integrated access and backhaul links is shown in FIG.1, where relay nodes (rTRPs) can multiplex access and backhaul links intime, frequency, or space (e.g. beam-based operation).

[FIG. 1 of 3GPP RP-172290, Entitled “Integrated Access and BackhaulLinks”, is Reproduced as FIG. 5]

The operation of the different links may be on the same or differentfrequencies (also termed ‘in-band’ and ‘out-band’ relays). Whileefficient support of out-band relays is important for some NR deploymentscenarios, it is critically important to understand the requirements ofin-band operation which imply tighter interworking with the access linksoperating on the same frequency to accommodate duplex constraints andavoid/mitigate interference.

In addition, operating NR systems in mmWave spectrum presents someunique challenges including experiencing severe short-term blocking thatmay not be readily mitigated by present RRC-based handover mechanismsdue to the larger time-scales required for completion of the procedurescompared to short-term blocking. Overcoming short-term blocking inmmWave systems may require fast RAN-based mechanisms for switchingbetween rTRPs, which do not necessarily require involvement of the corenetwork. The above described need to mitigate short-term blocking for NRoperation in mmWave spectrum along with the desire for easier deploymentof self-backhauled NR cells creates a need for the development of anintegrated framework that allows fast switching of access and backhaullinks. Over-the-air (OTA) coordination between rTRPs can also beconsidered to mitigate interference and support end-to-end routeselection and optimization.

SA1 has already established service requirements for wirelessself-backhauling (TS 22.261, Service requirement for the 5G System,section 6.12.2). These requirements are:

-   -   The 5G network shall enable operators to support wireless        self-backhaul using NR and E-UTRA.    -   The 5G network shall support flexible and efficient wireless        self-backhaul for both indoor and outdoor scenarios.    -   The 5G network shall support flexible partitioning of radio        resources between access and backhaul functions.    -   The 5G network shall support autonomous configuration of access        and wireless self-backhaul functions.    -   The 5G network shall support multi-hop wireless        self-backhauling.        -   NOTE 1: This is to enable flexible extension of range and            coverage area.    -   The 5G network shall support autonomous adaptation on wireless        self-backhaul network topologies to minimize service        disruptions.    -   The 5G network shall support topologically redundant        connectivity on the wireless self-backhaul.        -   NOTE 2: This is to enhance reliability and capacity and            reduce latency.

Objective 4.1 Objective of SI or Core Part WI or Testing Part WI

The objective of the study is to identify and evaluate potentialsolutions for the following requirements and aspects associated with theefficient operation of integrated access and wireless backhaul for NR.Frequency ranges up to 100 GHz will be considered.

Detailed objectives of the study item are:

-   -   Topology management for single-hop/multi-hop and redundant        connectivity [RAN2, RAN3], e.g.        -   Protocol stack and network architecture design (including            interfaces between rTRPs) considering operation of multiple            relay hops between the anchor node (e.g. connection to core)            and UE        -   Control and User plane procedures, including handling of            QoS, for supporting forwarding of traffic across one or            multiple wireless backhaul links    -   Route selection and optimization [RAN2, RAN1, RAN3], e.g.        -   Mechanisms for discovery and management of backhaul links            for TRPs with integrated backhaul and access functionalities        -   RAN-based mechanisms to support dynamic route selection            (potentially without core network involvement) to            accommodate short-term blocking and transmission of            latency-sensitive traffic across backhaul links        -   Evaluate the benefit of resource allocation/route management            coordination across multiple nodes, for end-to-end route            selection and optimization.    -   Dynamic resource allocation between the backhaul and access        links [RAN1, RAN2], e.g.,        -   Mechanisms to efficiently multiplex access and backhaul            links (for both DL and UL directions) in time, frequency, or            space under a per-link half-duplex constraint across one or            multiple backhaul link hops for both TDD and FDD operation        -   Cross-link interference (CLI) measurement, coordination and            mitigation between rTRPs and UEs    -   High spectral efficiency while also supporting reliable        transmission [RAN1]        -   Identification of physical layer solutions or enhancements            to support wireless backhaul links with high spectral            efficiency    -   Note: support of these functionalities should consider existing        mechanisms for access links as a starting point

3GPP TR 38.874 provides the following description related to IAB:

Architectures

Editor's note: This section is to describe architecture optionsidentified for supporting IAB.

6.1 General 6.1.1 Functions and Interfaces for IAB [FIG. 6.1.1-1 of 3GPPTR 38.874 V0.3.2, Entitled “Reference Diagram for IAB-Architectures (SAMode)”, is Reproduced as FIG. 6]

IAB strives to reuse existing functions and interfaces defined foraccess. In particular, Mobile-Termination (MT), gNB-DU, gNB-CU, UPF, AMFand SMF as well as the corresponding interfaces NR Uu (between MT andgNB), F1, NG, X2 and N4 are used as baseline for the IAB architectures.Modifications or enhancements to these functions and interfaces for thesupport of IAB will be explained in the context of the architecturediscussion. Additional functionality such as multi-hop forwarding isincluded in the architecture discussion as it is necessary for theunderstanding of IAB operation and since certain aspects may requirestandardization.

The Mobile-Termination (MT) function has been defined a component of theMobile Equipment. In the context of this study, MT is referred to as afunction residing on an IAB-node that terminates the radio interfacelayers of the backhaul Uu interface toward the IAB-donor or otherIAB-nodes.

FIG. 6.1.1-1 shows a reference diagram for IAB in standalone mode, whichcontains one IAB-donor and multiple IAB-nodes. The IAB-donor is treatedas a single logical node that comprises a set of functions such asgNB-DU, gNB-CU-CP, gNB-CU-UP and potentially other functions. In adeployment, the IAB-donor can be split according to these functions,which can all be either collocated or non-collocated as allowed by 3GPPNG-RAN architecture. IAB-related aspects may arise when such split isexercised, which will be explored at a later stage of the study. Also,some of the functions presently associated with the IAB-donor mayeventually be moved outside of the donor in case it becomes evident thatthey do not perform IAB-specific tasks.

6.2.2 IAB Architectures Proposed

All IAB multi-hop designs submitted to RAN-3#99 can be represented withfive architecture reference diagrams ([2]-[11]). These referencediagrams differ with respect to the modification needed on interfaces oradditional functionality needed, e.g. to accomplish multi-hopforwarding. These five architectures are divided into two architecturegroups. The main features of these architectures can be summarized asfollows:

Architecture group 1: Consists of architectures 1a and 1b. Botharchitectures leverage CU/DU split architecture.

-   -   Architecture 1a:        -   Backhauling of F1-U uses an adaptation layer or GTP-U            combined with an adaptation layer.        -   Hop-by-hop forwarding across intermediate nodes uses the            adaptation layer for operation with NGC or            PDN-connection-layer routing for operation with EPC.    -   Architecture 1b:        -   Backhauling of F1-U on access node uses GTP-U/UDP/IP.        -   Hob-by-hop forwarding across intermediate node uses the            adaptation layer.

Architecture group 2: Consists of architectures 2a, 2b and 2c

-   -   Architecture 2a:        -   Backhauling of F1-U or NG-U on access node uses            GTP-U/UDP/IP.        -   Hop-by-hop forwarding across intermediate node uses            PDU-session-layer routing.    -   Architecture 2b:        -   Backhauling of F1-U or NG-U on access node uses            GTP-U/UDP/IP.        -   Hop-by-hop forwarding across intermediate node uses            GTP-U/UDP/IP nested tunnelling.    -   Architecture 2c:        -   Backhauling of F1-U or NG-U on access node uses            GTP-U/UDP/IP.        -   Hop-by-hop forwarding across intermediate node uses            GTP-U/UDP/IP/PDCP nested tunnelling.

6.3 Architecture Group 1 6.3.1 Overview 6.3.1.1 Architecture 1a

[FIG. 6.3.1-1 of 3GPP TR 38.874 V0.3.2, Entitled “Reference Diagram forArchitecture 1a (SA-Mode with NGC)”, is Reproduced as FIG. 7]

Architecture 1a leverages CU/DU-split architecture. FIG. 6.3.1-1 showsthe reference diagram for a two-hop chain of IAB-nodes underneath anIAB-donor, where IAB-node and UE connect in SA-mode to an NGC.

In this architecture, each IAB-node holds a DU and an MT. Via the MT,the IAB-node connects to an upstream IAB-node or the IAB-donor. Via theDU, the IAB-node establishes RLC-channels to UEs and to MTs ofdownstream IAB-nodes. For MTs, this RLC-channel may refer to a modifiedRLC*. Whether an IAB-node can connect to more than one upstream IAB-nodeor IAB-donor is FFS.

The donor also holds a DU to support UEs and MTs of downstreamIAB-nodes. The IAB-donor holds a CU for the DUs of all IAB-nodes and forits own DU. It is FFS if different CUs can serve the DUs of theIAB-nodes. Each DU on an IAB-node connects to the CU in the IAB-donorusing a modified form of F1, which is referred to as F1*. F1*-U runsover RLC channels on the wireless backhaul between the MT on the servingIAB-node and the DU on the donor. F1*-U transport between MT and DU onthe serving IAB-node as well as between DU and CU on the donor is FFS.An adaptation layer is added, which holds routing information, enablinghop-by-hop forwarding. It replaces the IP functionality of the standardF1-stack. F1*-U may carry a GTP-U header for the end-to-end associationbetween CU and DU. In a further enhancement, information carried insidethe GTP-U header may be included into the adaption layer. Further,optimizations to RLC may be considered such as applying ARQ only on theend-to-end connection opposed to hop-by-hop. The right side of FIG.6.3.1-1 shows two examples of such F1*-U protocol stacks. In thisfigure, enhancements of RLC are referred to as RLC*. The MT of eachIAB-node further sustains NAS connectivity to the NGC, e.g., forauthentication of the IAB-node. It further sustains a PDU-session viathe NGC, e.g., to provide the IAB-node with connectivity to the OAM.

For NSA operation with EPC, the MT is dual-connected with the networkusing EN-DC. The IAB-node's MT sustains a PDN connection with the EPC,e.g., to provide the IAB-node with connectivity to the OAM.

Details of F1*, the adaptation layer and RLC* remain to be studied.Details of hop-by-hop forwarding are FFS. Transport of F1-AP is FFS.Protocol translation between F1* and F1 in case the IAB-donor is splitis FFS.

6.3.1.2 Architecture 1b

[FIG. 6.3.1-2 of 3GPP TR 38.874 V0.3.2, Entitled “Reference Diagram forArchitecture 1b (SA-Mode with NGC)”, is Reproduced as FIG. 8]

Architecture 1b also leverages CU/DU-split architecture. FIG. 6.3.1-2shows the reference diagram for a two-hop chain of IAB-nodes underneathan IAB-donor. Note that the IAB-donor only holds one logical CU. Whetheran IAB-node can connect to more than one upstream IAB-node or IAB-donoris FFS.

In this architecture, each IAB-node and the IAB-donor hold the samefunctions as in architecture 1a. Also, as in architecture 1a, everybackhaul link establishes an RLC-channel, and an adaptation layer isinserted to enable hop-by-hop forwarding of F1*.

Opposed to architecture 1a, the MT on each IAB-node establishes aPDU-session with a UPF residing on the donor. The MT's PDU-sessioncarries F1* for the collocated DU. In this manner, the PDU-sessionprovides a point-to-point link between CU and DU. On intermediate hops,the PDCP-PDUs of F1* are forwarded via adaptation layer in the samemanner as described for architecture 1a. The right side of FIG. 6.3.1-2shows an example of the F1*-U protocol stack.

For NSA operation with EPC, the MT is dual-connected with the networkusing EN-DC. In this case, the IAB-node's MT sustains a PDN connectionwith a L-GW residing on the donor.

[ . . . ]

9 Backhaul Aspects

Editor's note: Primary responsible WG for this clause is RAN3.

9.1 Additional Interfaces

[ . . . ]

9.2 IAB Topologies

The following IAB topologies are considered in the study:

-   -   1. Spanning tree (ST)    -   2. Directed acyclic graph (DAG)        [FIGS. 9.2-1 of 3GPP TR 38.874 V0.3.2, Entitled “Examples for        Spanning Tree and Directed Acyclic Graph. The Array Indicates        the Directionality of the Graph Edge”, is Reproduced as FIG. 9]

The directionality of the Uu-backhaul link, defined by uplink anddownlink, is aligned with the hierarchy of the ST or DAG.

For ST, each IAB-node has only one parent node, which can be anotherIAB-node or the IAB-donor. Each IAB-node is therefore connected to onlyone IAB-donor at a time, and only one route exists between IAB-node andthis IAB-donor.

[FIGS. 9.2-2 of 3GPP TR 38.874 V0.3.2, Entitled “Examples for Link- andRoute Redundancy in DAG”, is Reproduced as FIG. 10]

For DAG, the following options can be considered:

-   -   The IAB-node is multi-connected, i.e., it has links to multiple        parent nodes (FIGS. 9.2-2a).    -   The IAB-node has multiple routes to another node, e.g. the        IAB-donor (FIGS. 9.2-2b).    -   Both options can be combined, i.e., the IAB-node may have        redundant routes to another node via multiple parents (FIGS.        9.2-2c).

Multi-connectivity or route redundancy may be used for back-up purposes.It is also possible that redundant routes are used concurrently, e.g.,to achieve load balancing, reliability, etc.

[FIGS. 9.2-3 of 3GPP TR 38.874 V0.3.2, Entitled “Route Redundancy inArch Group 1”, is Reproduced as FIG. 11]

For architecture group 1, the following scenarios can be considered foran IAB-node with redundant routes (FIG. 3). These routes may pertain to:

-   -   The same IAB-donor DU, and therefore the same IAB-donor CU-CP        and CU-UP (FIGS. 9.2-3a),    -   Different IAB-donor DUs, but same IAB-donor CU-CP and CU-UP        (FIGS. 9.2-3b),    -   Different IAB-donor DUs, different IAB-donor CU-UP, but same        IAB-donor CU-CP (FIGS. 9.2-3c),    -   Different IAB-donor DUs, CU-CP and CU-UP (FIGS. 9.2-3d).

[FIGS. 9.2-4 of 3GPP TR 38.874 V0.3.2, Entitled “Examples for Link- andRoute Redundancy in Arch Group 2”, is Reproduced as FIG. 12]

For architecture group 2, the following scenarios need to be consideredfor an IAB-node with redundant routes. These routes may pertain to:

-   -   The same IP domain (FFS),    -   Different IP domains (FFS).

For at least some of these topologies, aspects of IP address managementas well as procedures for topology adaptation will be studied. Furtherprioritization of these topologies may be necessary.

9.3 Integration of IAB-Node

IAB-node integration has the following phases:

-   -   1. The IAB-node authenticates with the operator's network and        establishes IP connectivity to reach OAM functionality for OAM        configuration.        -   This phase includes discovery and selection of a serving            node, which can be an IAB-donor or another IAB-node. The            IAB-node may retrieve this information, e.g. from OAM or via            RAN signaling such as OSI or RRC.        -   This phase further includes setting up connectivity to other            RAN nodes and CN.        -   This phase involves the MT function on the IAB-node.    -   2. The IAB-node's DU, gNB, or UPF are set up together with all        interfaces to other RAN-nodes and CN. This phase must be        performed before the IAB node can start serving UEs or before        further IAB-nodes can connect.        -   For architectures 1a and 1b, this phase involves setup of            the IAB-node's DU and the F1-establishment to the            IAB-donor's CU-CP and CU-UP.        -   For architecture 2a, this phase involves setup of the            IAB-node's gNB and UPF as well as integration into the            PDU-session forwarding layer across the wireless backhaul.        -   This phase includes the IAB-node's integration into topology            and route management.    -   3. The IAB-node provides service to UEs or to other integrated        IAB-nodes.        -   UEs will not be able to distinguish access to the IAB-node            from access to gNBs.

9.4 Modifications to CU/DU Architecture 9.4.1 Modifications ofIAB-Donor/IAB-Node DU and IAB-Donor CU for Architecture Group 1

The study assumes that Rel 15 F1-U is considered as the baseline betweenthe IAB-donor DU and the IAB-donor CU. If this baseline does not meetthe requirements of the SI, then the study will consider potentialmodifications to Rel 15 F1-U.

The study will further consider modifications to the IAB-node DU thatare necessary to support F1*-U over the wireless NR backhaul.

[ . . . ]

In general, an IAB-node is a RAN (Radio Access Network) node thatsupports wireless access to UEs and wirelessly backhauls the accesstraffic. An IAB-donor is generally a RAN node which provides UE'sinterface to core network and wireless backhauling functionality toIAB-nodes. The IAB-node may also be referred to as a rTRP (relay TRP).The IAB-donor may also be referred to as anchor node.

A parent node of an IAB-node may be a node connected to the IAB-node andthe (transmission) direction from the IAB-node to the parent node isuplink direction. A child node of an IAB-node may be a node connected tothe IAB-node and the direction from the IAB-node to the child node isdownlink direction. The IAB-node has a direct link to its parent node orchild node. The IAB-node may be served by its parent node. The IAB-nodemay serve its child node. The IAB-node may be scheduled by its parentnode. The IAB-node may schedule its child node.

Each IAB-node may include a NW (network) part and a MT (mobiletermination) part. The NW part has at least part of the functionalitiesthat a typical NW (e.g. a gNB DU) should have. The MT part has at leastpart of the functionalities that a typical UE (e.g. a mobile phone)should have.

An IAB-node generally acts as NW through its NW part when it interactswith its child node. The child node could be a UE. The child node couldbe another IAB-node. An IAB-node acts as UE through its MT part when itinteracts with its parent node. The parent node could be anotherIAB-node. The parent node could be an IAB-donor. An IAB-node may be ableto act as NW and UE at the same time. An IAB-node may act either as NWor as UE at a time (e.g. in time-division manner).

An IAB system could include at least one IAB-donor and at least oneIAB-node. An IAB system may have at most one IAB-donor. An IAB systemmay include one IAB topology. The IAB topology may be spanning tree (ST)or directed acyclic graph (DAG). Nodes belonging to the same IABtopology are within the same IAB system. The directionality (e.g. uplinkand downlink) is aligned with the hierarchy of the topology of the IABsystem (details are in Section 9.2 of 3GPP TR 38.874). For example, theIAB-donor has the highest level. The direction from a higher-level nodeto a lower-level node is defined as downlink, and the direction from alower-level node to a higher-level node is defined as uplink.

A sub-branch of an IAB system is a subset of the IAB system, wherein thesub-branch includes a root node (could also be referred to as head orhead node) and at least one IAB-node connecting to the root node as thechild node of the root node. The parent node of the head node is outsidethe sub-branch. In case the head node is the IAB-donor, the sub-branchis equivalent to the entire IAB system.

It may be assumed that when an IAB-node acts as UE, it acquires UL(Uplink) resources by transmitting a signaling to its parent node. Thesignaling could be a Scheduling Request (SR). The signaling could betransmitted on a UL control channel, e.g. PUCCH (Physical Uplink ControlChannel). The UL control channel is a UL channel between the IAB-nodeand the parent node. The signaling could be a Radom Access (RA)Preamble. The RA Preamble could be transmitted on PRACH (Physical RandomAccess Channel). The PRACH is a UL channel between the IAB-node and theparent node. After receiving the signaling, the parent node may provideUL grant to the IAB-node transmitting the signaling. The IAB-node couldthen perform UL data transmission on PUSCH (Physical Uplink SharedChannel) based on the received UL grant. The UL grant could be a DCI(Downlink Control Information) received on a downlink control channel,e.g. PDCCH (Physical Downlink Control Channel). The PUSCH is a ULchannel between the IAB-node and the parent node. The PDCCH is a DL(Downlink) channel between the IAB-node and the parent node. In thisparagraph, the IAB-node acts as UE and the parent node acts as NW.

When a UE directly connects to an IAB-node, the IAB-node is referred toas an access node of the UE. The link between a UE and an IAB-node isreferred to as access link. In one embodiment, there is another IAB-nodebetween the access node and the IAB-donor, and the other IAB-node isreferred to as an intermediate node of the UE. The access node may alsobe considered as an intermediate node. The link between one IAB-node andanother IAB-node (or IAB-donor) is referred to as backhaul link. AnIAB-node could have one or multiple child nodes. An IAB-node could haveone or multiple parent nodes. There could be one or multiple routesbetween IAB-node and IAB-donor depending on topology. It is assumed thatIAB-donor has the full knowledge of the topology.

There could be multi-hop in an IAB system. FIG. 13 is an example of asingle IAB system, wherein four UEs target on the same IAB-donor, butwith the same or different number of hops (i.e. number of intermediatenodes). In FIG. 13, the UE 1 and the UE 3 have the same number of hops.Multi-hop backhauling provides more range extension than single hop.

The backhaul link could be in-band or out-of-band with respect to theaccess link, depending on whether the backhaul link and the access linkare at least partially overlapped in frequency or not. In-bandbackhauling creates half-duplexing or interference constraints, whichimply that the IAB-node cannot transmit and receive simultaneously onboth links.

An IAB-node could be physically fixed (i.e. its location is fixed) ormobile (e.g. on buses or trains). The relay of an IAB system could beL2-relay or L3-relay, depending on the architecture of the IAB system.The resource coordination between IAB-nodes could be distributed orcentralized.

When DL data arrives at an IAB-node but the destination is not thisIAB-node, the IAB-node may forward (relay) the DL data to its child nodeaccording to routing table configured for this IAB-node. The routingtable is configured, for example, by IAB-donor based on topology of theIAB system. The routing table could be stored at this IAB-node.

FIG. 14 is an example of an IAB-system and routing tables for differentnodes. In this example, there are two routes (i.e. through Node 2 andNode 3) between Node 5 and IAB-donor. When DL data for Node 5 arrive atNode 1, the Node 1 checks its routing table, and may forward the DL datato either Node 2 or Node 3 because both links are routable (i.e. DL datafor Node 5 could be sent on either link). In case of UL data arrival,usually the destination is IAB-donor, and the IAB-node may just forwardUL data to one of its parent nodes. A routing table for UL direction maythus be unnecessary. The route could also be referred to as routing orrouting path.

The topology of an IAB system may be determined at the beginning ofsystem setup. The topology and/or the routing of some or all IAB-nodes(may also include IAB-donor) in the IAB system may then be updated whenan IAB-node is added to/removed from the IAB system, parent node change(e.g. link problem of serving parent node, load balancing, . . . ) orwhen the location of an existing IAB-node changes (e.g. a mobileIAB-node). The routing tables should also be updated when topologychanges. For fixed-location IAB-nodes, the topology should be stable andis not updated frequently.

Given that the IAB-donor should have full knowledge of topologyinformation, the update of routing table for an IAB-node may beinitiated by the IAB-donor. The IAB-donor may be responsible forupdating the routing table of each node whose routing is affected. Forexample, if there are in total 5 IAB-nodes to be updated due to topologychange, the IAB-donor will transmits in total 5 separated messages,wherein each message terminates at different target IAB-node forupdating the target IAB-node. This update scheme could be referred to asend-to-end routing table update. Each message goes through theintermediate nodes (and backhaul links) between IAB-donor and the targetIAB-node, and some intermediate nodes of different target IAB-node maybe the same. One drawback of this end-to-end update is that if there aremany IAB-nodes needing update, the signaling overhead on backhaul linksbecomes high. Intermediate nodes shared by many target IAB-nodes willalso have high loading. FIG. 15 illustrates this issue.

As shown in FIG. 15, when parent node of Node 8 is changed from Node 7to Node 6, routing tables for IAB-nodes including Node 3, Node 5, Node 6and Node 7 need to be updated. If the routing table update is signaledby the IAB-donor, the signaling to update routing table of Node 3 istransmitted from Donor to Node 3 via Node 1. The signaling to updaterouting table of Node 5 is transmitted from Donor to Node 5 via Node 1and Node 3. The signaling to update routing table of Node 6 istransmitted from Donor to Node 6 via Node 1 and Node 3. The signaling toupdate routing table of Node 7 is transmitted from Donor to Node 7 viaNode 1, Node 3, and Node 5. In this example, Node 1 & Node 3, as well asthe backhaul links between Donor and Node 3, have highest loading. InFIG. 15, the Donor could be an IAB-donor; nodes other than the Donorcould be an IAB-node; and nodes other than the Donor could be a UE.

To reduce the overhead for routing table update, the update of routingtable for an IAB-node may be initiated by another IAB-node. For example,a first IAB-node could indicate a second IAB-node to update a routingpath maintained by the second IAB-node. The first IAB-node may not be anIAB-donor. The second IAB-node may not be an IAB-donor. The firstIAB-node may transmit a message to the second IAB-node for updating arouting path. The first IAB-node may indicate the second IAB-node toupdate the routing path in response to receiving a message of routingpath update from an IAB-donor of the first IAB-node. The first IAB-nodemay also indicate the second IAB-node to update the routing path inresponse to receiving a message of routing path update from a parentnode of the first IAB-node. The first IAB-node may update a routing pathmaintained by the first IAB-node in response to receiving a message ofrouting path update from an IAB-donor. The first IAB-node may alsoupdate a routing path maintained by the first IAB-node in response toreceiving a message of routing path update from a parent node of thefirst IAB-node. The first IAB-node may indicate the second IAB-node toupdate the routing path in response to detection of backhaul linkfailure (or backhaul link recovery).

The backhaul link failure (or backhaul link recovery) may occur in adescendant node of the first IAB-node. The second IAB-node may be achild node of the first IAB-node. The second IAB-node may also be adescendant node of the first IAB-node. The first IAB-node may transmitinformation about the routing path update to the IAB-donor. A descendantnode may be a node wherein the direction toward the node is downlinkdirection and there is at least one intermediate node in between.

One way is to perform hop-by-hop update (instead of end-to-end update).For example, each IAB-node's routing table is updated by this node'sparent node which has fewer hops compared to IAB-donor, and then thisnode continues updating its child node if needed. Another way is toperform local update which is not handled by IAB-donor. As anotherexample, within a sub-branch of the IAB system, each node's routingtable is updated by the head node of this sub-branch. A head node of asub-branch could be the node with fewest hops to the IAB-donor. A headnode of a sub-branch could also be the top-most node in the sub-branchwhose parent node is outside the sub-branch.

Given the above two ways, some alternatives are described below, and thealternatives may be used jointly. In one alternative, IAB-donorinitiates hop-by-hop routing table update on head node of a sub-branch.Based on the method of routing table update describe above andillustrated in FIG. 15, several separated routing table update messagesgoing through the same backhaul link (e.g. the backhaul links betweenDonor and Node 3 in FIG. 15) results in high signaling overhead. Toavoid this, the IAB-donor could firstly update the IAB-node which hasfewest hops to the IAB-donor among the IAB-nodes required to be updated(e.g. Node 3 in FIG. 16, the head IAB-node of a sub-branch). TheIAB-node then determines whether its child node needs update or not. Ifit determines that update is needed, the IAB-node transmits routingtable update message to its child node. The child node then repeats thehop-by-hop update if needed.

An example of the hop-by-hop update initiated by IAB-donor isillustrated in FIG. 16. The Donor firstly transmits update message toNode 3 via Node 1. After being updated by Donor, Node 3 (determines to)transmits update message to Node 5 and Node 6. After it has been updatedby Node 3, Node 5 (determines to) transmits update message to Node 7. InFIG. 16, the Donor could be an IAB-donor. Nodes other than the Donorcould be an IAB-node or a

UE.

The determination could be based on differences between old routingtable and new routing table for this node, and then routing table updatemessage for child node could be generated by this IAB-node.Alternatively, the routing table update message for nodes belonging tosub-branch of this IAB-node could also be carried in the update messagefor this IAB-node, and this IAB-node determines to forward updatemessage to its child node if such message exists.

Since that there could be multiple routes between one IAB-node andanother IAB-node, an IAB-node may receive the same routing table updatemessage more than once. In this case, the same message could be regardedas duplicated message and the IAB-node could just discard the duplicatedmessage.

In another alternative, IAB-donor initiates end-to-end routing tableupdate on head node of a sub-branch. It is possible that topology changeresults in routing table update within one (small) sub-branch of theentire IAB system topology. The IAB-donor could firstly transmit updatemessage to the head IAB-node (referred to as head or head node in thefollowing) of the sub-branch. Then the head node of the sub-branch couldtransmit separated routing update message to each of the IAB-nodes underthis head node.

An example is illustrated in FIG. 17. First, the Donor transmits updatemessage to Node 3 (head node of a sub-branch) via Node 1. After beingupdated by Donor, Node 3 determines that Nodes 5, 6, and 7 also need tobe updated. Node 3 transmits update message to Node 5. Node 3 transmitsupdate message to Node 6. Node 3 transmits update message to Node 7 viaNode 5. In FIG. 17, the Donor could be an IAB-donor. In FIG. 17, nodesother than the Donor could be an IAB-node or a UE.

The determination could be based on differences between old routingtable and new routing table for this head node, and then routing tableupdate message for nodes under this head node could be generated by thishead node. Alternatively, the routing table update message for nodesbelonging to sub-branch of this head node could also be carried in theupdate message for this head node, and this head node determines toforward update message to nodes under this head node if such messageexists.

Since the update messages for nodes under the head node is transmittedby the head node itself, there should be no duplicated update messagesas compared to alternative 1. In case IAB-donor is the head node of thesub-branch, this alternative reduced to pure end-to-end update.

In another alternative, at least some routing table update is initiatedby the head node of a sub-branch directly instead of by the IAB-donor(i.e. local update). For example, if an IAB-node changes its parent nodefrom one node to another node within a sub-branch, routing tables ofIAB-nodes out-side this sub-branch do not need to be updated. TheIAB-donor still forward DL data to the head node of this sub-branch, andthen nodes (including head node) in the sub-branch will forward DL dataaccording to the updated routing table. In this case, the head nodecould directly initiates routing table update using hop-by-hop orend-to-end as described above. For hop-by-hop, the head node firstupdates its routing table, and then updates its child node by generatingand transmitting update message to its child. For end-to-end, the headnode first updates its routing table, and then updates nodes under it bygenerating and transmitting separated update message to nodes under it.

FIG. 18 is an example of hop-by-hop update initiated by the head node ofa sub-branch. Node 3 first updates its routing table. After beingupdated by itself, Node 3 (determines to) transmits update message toNodes 5 and 6. After being updated by Node 3, Node 5 (determines to)transmits update message to Node 7. FIG. 19 is an example of end-to-endupdate initiated by the head node of a sub-branch. Node 3 firstlyupdates its routing table. After being updated by itself, Node 3determines that Nodes 5, 6, and 7 also need to be updated. Node 3transmits update message to Node 5. Node 3 transmits update message toNode 6. Node 3 transmits update message to Node 7 via Node 5. In FIG.18, the Donor could be an IAB-donor. In FIG. 18, nodes other than theDonor could be an IAB-node or a UE. In FIG. 19, the Donor could be anIAB-donor. In FIG. 19, nodes other than the Donor could be an IAB-nodeor a UE.

Additionally, the head node could inform IAB-donor about the update. Thehead node could inform IAB-donor when the head node initiates theupdate. Additionally or alternatively, the head node could informIAB-donor after completion of the update.

There may exist multiple routing paths for the same IAB-node. It ispossible that one routing path is active at one time. An active routingpath means that the IAB-node is allowed to use the routing path totransmit packets. It is also possible that more than one routing pathare active at the same time. Multi-connectivity may be used to realizemultiple active routing paths. For example, an IAB-node could beconfigured with multiple parent nodes. One of the parent node could beconfigured as PCell (or SpCell), and other parent nodes could beconfigured as SCells. A backhaul link may be activated or deactivateddynamically. The link between SCell parent and IAB-node could beactivated or deactivated when SCell parent is activated/deactivated fromthe IAB-nodes perspective. Activation or deactivation of SCell parentnode could thus affect whether the backhaul link is actually routable ornot.

The update of routing table due to activation or deactivation could beachieved by normal routing table update procedure. Additionally oralternatively, the update of routing table due to activation ordeactivation could be achieved by one or combination of the alternativesdescribed above, such as hop-by-hop or end-to-end or being initiated bythe IAB-donor or by a head node of a sub-branch. The PCell parent nodeand SCell parent node could belong to the same sub-branch.

The update of routing table due to activation or deactivation could beachieved by firstly constructing a complete routing table for a headnode of a sub-branch, in which both PCell link and SCell link within thesub-branch are set to routable. Then, a mask or valid bit could be addedto the routing table for the head node. Each entry of the mask or eachvalid bit could indicate whether the corresponding link is activated ordeactivated. Additionally or alternatively, each entry of the mask oreach valid bit could indicate whether the corresponding Node isactivated or deactivated. Upon activation or deactivation of a link or aNode, the mask or the valid bit could be updated by the head nodeitself. Each node could maintain the mask or valid bit by itself.

FIG. 20 is a flow chart 2000 according to one exemplary embodiment fromthe perspective of a first node. In step 2005, the first node transmitsa first message to a second node, for updating a second routing pathmaintained by the second node. In one embodiment, the first node couldtransmit the first message in response to receiving a second message ofrouting path update from a third node. Additionally or alternatively,the first node could transmit the first message in response to detectionof backhaul link failure (or recovery) of a descendant node.

In one embodiment, the first node could update a first routing pathmaintained by the first node in response to receiving the second messageof routing path update from the third node. Additionally oralternatively, the first node could transmit information about therouting path update to an IAB (Integrated Access and Backhaul) donor ofthe first node.

In one embodiment, the second node could be a child node of the firstnode. The child node could be a node connected to the first node and thedirection from the first node to the child node is downlink direction.The first node could serve the child node. Additionally oralternatively, the second node could be a descendant node of the firstnode. There could be at least one intermediate node between the firstnode and the descendant node and the direction from the first node tothe descendant node is downlink direction.

In one embodiment, the third node could be a parent node of the firstnode. The parent node could be a node connected to the first node andthe direction from the first node to the parent node is uplinkdirection. The first node could be served by the parent node.Additionally or alternatively, the third node could be an IAB donor ofthe first node. The IAB donor could be a RAN node which provides UEinterface to core network and wireless backhauling functionality to IABnodes.

In one embodiment, the first node and/or the second node may not be anIAB donor.

Referring back to FIGS. 3 and 4, in one exemplary embodiment of a firstnode, the communication device 300 includes a program code 312 stored inthe memory 310. The CPU 308 could execute program code 312 to enable thefirst node to transmit a first message to a second node, for updating asecond routing path maintained by the second node. Furthermore, the CPU308 can execute the program code 312 to perform all of theabove-described actions and steps or others described herein.

FIG. 21 is a flow chart 2100 according to one exemplary embodiment fromthe perspective of a first node. In step 2105, the first node determinesthat a first routing path maintained by the first node needs to bemodified. In step 2110, the first node modifies the first routing path.In step 2115, the first node transmits a second message to a third nodefor modifying a second routing path maintained by the third node.

In one embodiment, the first node could determine that the first routingpath needs to be modified by receiving a first message for modifying thefirst routing path from a second node. Additionally or alternatively,the first node could determine that the first routing path needs to bemodified by receiving a first message for modifying the first routingpath from a forth node.

In one embodiment, the first node could modify the first routing path inresponse to reception of the first message. Additionally oralternatively, the first node could modify the first routing path basedon the first message.

In one embodiment, the first node could determine whether the third nodeneeds to modify the second routing path in response to reception of thefirst message. The first node could also determine that the third nodeneeds to modify the second routing path if the first message indicatesthat the third node needs to modify the second routing path. Inaddition, the first node could determine whether the third node needs tomodify the second routing path in response to modification of the firstrouting path. Furthermore, the first node could determine that the thirdnode needs to modify the second routing path based on differencesbetween the first routing path before update and the first routing pathafter update.

In one embodiment, the first node could transmit the second message ifthe first node determines that the third node needs to modify the secondrouting path. Furthermore, the first node may not transmit the secondmessage if the first node determines that the third node does not needto modify the second routing path. The first node could also transmitthe second message after modifying the first routing path.

In one embodiment, the first node could inform a fourth node about theupdate of routing table. The first routing path could be a routing tablestored in the first node. The modification of the first routing pathcould be addition, removal, and/or updating of the first routing path.The second message could be the same as the first message.

In one embodiment, the first node could be an IAB-node or an IAB-donor.Furthermore, the first node could be a child node of the second node.Alternatively, the first node may not be a child node of the secondnode, and may be below the second node from topology point of view.

In one embodiment, the first node could be a parent node of the thirdnode. Alternatively, the first node may not be a parent node of thethird node, and may be above the third node from topology point of view.

In one embodiment, the second node may be an IAB-node or an IAB-donor.Furthermore, the second node may be a parent node of the first node.Alternatively, the second node may not be a parent node of the firstnode, and may be above the first node from topology point of view.

In one embodiment, the third node may be an IAB-node. Furthermore, thethird node may be a child node of the first node. Alternatively, thethird node may not be a child node of the first node, and may be belowthe first node from topology point of view.

In one embodiment, the fourth node may not be the second node.Alternatively, the fourth node may be the second node. The fourth nodecould be an IAB-donor. Furthermore, the fourth node could be a childnode of the first node. Alternatively, the fourth node may not be achild node of the first node and is below the first node from topologypoint of view.

In one embodiment, there may be a direct link between two nodes if onenode is either a parent node or a child node of another node.Furthermore, there may be no direct link between two nodes if one nodeis neither a parent node nor a child node of another node.

Referring back to FIGS. 3 and 4, in one exemplary embodiment of a firstnode, the communication device 300 includes a program code 312 stored inthe memory 310. The CPU 308 could execute program code 312 to enable thefirst node (i) to determine that a first routing path maintained by thefirst node needs to be modified, (ii) to modify the first routing path,and (iii) to transmit a second message to a third node for modifying asecond routing path maintained by the third node. Furthermore, the CPU308 can execute the program code 312 to perform all of theabove-described actions and steps or others described herein.

Various aspects of the disclosure have been described above. It shouldbe apparent that the teachings herein could be embodied in a widevariety of forms and that any specific structure, function, or bothbeing disclosed herein is merely representative. Based on the teachingsherein one skilled in the art should appreciate that an aspect disclosedherein could be implemented independently of any other aspects and thattwo or more of these aspects could be combined in various ways. Forexample, an apparatus could be implemented or a method could bepracticed using any number of the aspects set forth herein. In addition,such an apparatus could be implemented or such a method could bepracticed using other structure, functionality, or structure andfunctionality in addition to or other than one or more of the aspectsset forth herein. As an example of some of the above concepts, in someaspects concurrent channels could be established based on pulserepetition frequencies. In some aspects concurrent channels could beestablished based on pulse position or offsets. In some aspectsconcurrent channels could be established based on time hoppingsequences. In some aspects concurrent channels could be establishedbased on pulse repetition frequencies, pulse positions or offsets, andtime hopping sequences.

Those of skill in the art would understand that information and signalsmay be represented using any of a variety of different technologies andtechniques. For example, data, instructions, commands, information,signals, bits, symbols, and chips that may be referenced throughout theabove description may be represented by voltages, currents,electromagnetic waves, magnetic fields or particles, optical fields orparticles, or any combination thereof.

Those of skill would further appreciate that the various illustrativelogical blocks, modules, processors, means, circuits, and algorithmsteps described in connection with the aspects disclosed herein may beimplemented as electronic hardware (e.g., a digital implementation, ananalog implementation, or a combination of the two, which may bedesigned using source coding or some other technique), various forms ofprogram or design code incorporating instructions (which may be referredto herein, for convenience, as “software” or a “software module”), orcombinations of both. To clearly illustrate this interchangeability ofhardware and software, various illustrative components, blocks, modules,circuits, and steps have been described above generally in terms oftheir functionality. Whether such functionality is implemented ashardware or software depends upon the particular application and designconstraints imposed on the overall system. Skilled artisans mayimplement the described functionality in varying ways for eachparticular application, but such implementation decisions should not beinterpreted as causing a departure from the scope of the presentdisclosure.

In addition, the various illustrative logical blocks, modules, andcircuits described in connection with the aspects disclosed herein maybe implemented within or performed by an integrated circuit (“IC”), anaccess terminal, or an access point. The IC may comprise a generalpurpose processor, a digital signal processor (DSP), an applicationspecific integrated circuit (ASIC), a field programmable gate array(FPGA) or other programmable logic device, discrete gate or transistorlogic, discrete hardware components, electrical components, opticalcomponents, mechanical components, or any combination thereof designedto perform the functions described herein, and may execute codes orinstructions that reside within the IC, outside of the IC, or both. Ageneral purpose processor may be a microprocessor, but in thealternative, the processor may be any conventional processor,controller, microcontroller, or state machine. A processor may also beimplemented as a combination of computing devices, e.g., a combinationof a DSP and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DSP core, or any other suchconfiguration.

It is understood that any specific order or hierarchy of steps in anydisclosed process is an example of a sample approach. Based upon designpreferences, it is understood that the specific order or hierarchy ofsteps in the processes may be rearranged while remaining within thescope of the present disclosure. The accompanying method claims presentelements of the various steps in a sample order, and are not meant to belimited to the specific order or hierarchy presented.

The steps of a method or algorithm described in connection with theaspects disclosed herein may be embodied directly in hardware, in asoftware module executed by a processor, or in a combination of the two.A software module (e.g., including executable instructions and relateddata) and other data may reside in a data memory such as RAM memory,flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a harddisk, a removable disk, a CD-ROM, or any other form of computer-readablestorage medium known in the art. A sample storage medium may be coupledto a machine such as, for example, a computer/processor (which may bereferred to herein, for convenience, as a “processor”) such theprocessor can read information (e.g., code) from and write informationto the storage medium. A sample storage medium may be integral to theprocessor. The processor and the storage medium may reside in an ASIC.The ASIC may reside in user equipment. In the alternative, the processorand the storage medium may reside as discrete components in userequipment. Moreover, in some aspects any suitable computer-programproduct may comprise a computer-readable medium comprising codesrelating to one or more of the aspects of the disclosure. In someaspects a computer program product may comprise packaging materials.

While the invention has been described in connection with variousaspects, it will be understood that the invention is capable of furthermodifications. This application is intended to cover any variations,uses or adaptation of the invention following, in general, theprinciples of the invention, and including such departures from thepresent disclosure as come within the known and customary practicewithin the art to which the invention pertains.

1. A method for a first node supporting wireless access and wirelessbackhaul, comprising: transmitting a first message to a second node, forupdating a second routing path maintained by the second node.
 2. Themethod of claim 1, wherein the first node transmits the first message inresponse to receiving a second message of routing path update from athird node.
 3. The method of claim 2, further comprising: the first nodeupdates a first routing path maintained by the first node in response toreceiving the second message of routing path update from the third node.4. The method of claim 1, wherein the first node transmits the firstmessage in response to detection of backhaul link failure (or backhaullink recovery) of a descendant node.
 5. The method of claim 1, furthercomprising: the first node transmits information about the routing pathupdate to an IAB (Integrated Access and Backhaul) donor of the firstnode.
 6. The method of claim 1, wherein the second node is a child nodeof the first node.
 7. The method of claim 1, wherein the second node isa descendant node of the first node.
 8. The method of claim 2, whereinthe third node is a parent node of the first node.
 9. The method ofclaim 2, wherein the third node is an IAB (Integrated Access andBackhaul) donor of the first node.
 10. The method of claim 1, whereinthe first node and/or the second node is not an IAB donor.
 11. Acommunication device, comprising: a control circuit; a processorinstalled in the control circuit; and a memory installed in the controlcircuit and operatively coupled to the processor; wherein the processoris configured to execute a program code stored in the memory to:transmit a first message to a second node, for updating a second routingpath maintained by the second node.
 12. The communication device ofclaim 11, wherein the first node transmits the first message in responseto receiving a second message of routing path update from a third node.13. The communication device of claim 12, wherein the processor isfurther configured to execute a program code stored in the memory to:the first node updates a first routing path maintained by the first nodein response to receiving the second message of routing path update fromthe third node.
 14. The communication device of claim 11, wherein thefirst node transmits the first message in response to detection ofbackhaul link failure (or backhaul link recovery) of a descendant node.15. The communication device of claim 11, wherein the processor isfurther configured to execute a program code stored in the memory to:transmit information about the routing path update to an IAB (IntegratedAccess and Backhaul) donor of the first node.
 16. The communicationdevice of claim 11, wherein the second node is a child node of the firstnode.
 17. The communication device of claim 11, wherein the second nodeis a descendant node of the first node.
 18. The communication device ofclaim 12, wherein the third node is a parent node of the first node. 19.The communication device of claim 12, wherein the third node is an IAB(Integrated Access and Backhaul) donor of the first node.
 20. Thecommunication device of claim 11, wherein the first node and/or thesecond node is not an IAB donor.